home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Windows 3-Pak 2 - Disc 2
/
Infomagic - Windows 3-Pak Volume 2 (Disc 2 of 3).iso
/
Chat---IRC
/
TURBOIRC.ZIP
/
data1.cab
/
TurboIRC_Help_Files
/
ircx.txt
< prev
next >
Wrap
Text File
|
1999-05-05
|
93KB
|
2,561 lines
INTERNET-DRAFT Dalen Abraham
Expires: December 16, 1998 Microsoft Corporation
June 1998
Extensions to the Internet Relay Chat Protocol (IRCX)
draft-pfenning-irc-extensions-04.txt
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).
2. Abstract
This document describes IRCX, a set of extensions to the
Internet Relay Chat (IRC) protocol defined in RFC 1459[1].
Only client-server interactions are defined. The added
functionality includes user authentication for multiple
security providers, support for UNICODE[2] characters,
multilayer security, and a unified property mechanism.
Chat server implementations can support channel or server
services with full control over all messages and events.
These services communicate with the core server over an
extended IRC connection.
All changes to the IRC protocol are designed such that
existing clients will continue to work against servers
implementing the extensions. Support for the extended protocol
can be queried by clients to take advantage of the added
functionality or to conform to the basic protocol as defined
in RFC1459.
[Page 1]
INTERNET-DRAFT IRCX June 1998
2.1. Contents
1. Status of this Memo.......................................1
2. Abstract..................................................1
2.1. Contents.............................................2
3. Modified UTF8 Encoding of UNICODE characters..............5
4. Terms and Definitions.....................................5
4.1. User Access Levels...................................6
4.2. Prefixes.............................................6
5. IRCX Client Messages......................................7
5.1. ACCESS command (new IRCX command)....................8
5.1.1. Parameters.......................................8
5.1.2. Results..........................................8
5.1.3. Possible Errors..................................9
5.1.4. Remarks..........................................9
5.1.5. Examples.........................................9
5.2. AUTH Command (new IRCX command).....................10
5.2.1. Parameters......................................10
5.2.2. Results.........................................10
5.2.3. Possible Errors.................................10
5.2.4. Remarks:........................................11
5.2.5. Example:........................................11
5.3. CREATE (new IRCX command)...........................11
5.3.1. Parameters......................................11
5.3.2. Results.........................................11
5.3.3. Possible Errors.................................11
5.3.4. Remarks.........................................12
5.3.5. Examples........................................12
5.4. DATA / REQUEST / REPLY (new IRCX command)...........12
5.4.1. Parameters......................................12
5.4.2. Results.........................................13
5.4.3. Possible Errors.................................13
5.4.4. Remarks.........................................13
5.4.5. Example.........................................13
5.5. EVENT (new IRCX command)............................13
5.5.1. Parameters......................................13
5.5.2. Results.........................................14
5.5.3. Possible Errors.................................14
5.5.4. Remarks.........................................14
5.5.5. Examples:.......................................14
5.6. IRCX (new IRCX command).............................15
5.6.1. Parameters......................................15
5.6.2. Results.........................................15
5.6.3. Example.........................................15
5.7. ISIRCX (new IRCX command)...........................15
5.7.1. Results.........................................15
5.8. LISTX (new IRCX command)............................15
5.8.1. Parameters......................................16
5.8.2. Results.........................................16
5.8.3. Remarks.........................................17
5.9. MODE (extension to RFC1459 command).................17
5.9.1. Results.........................................17
5.9.2. Remarks.........................................17
5.10. NOTICE (extension to RFC1459 command)...............18
[Page 2]
INTERNET-DRAFT IRCX June 1998
5.10.1.Results.........................................18
5.11. PRIVMSG (extension to RFC1459 command)..............18
5.11.1.Results.........................................18
5.12. PROP (new IRCX command).............................18
5.12.1.Results.........................................18
5.12.2.Possible Errors.................................19
5.12.3.Remarks.........................................19
5.12.4.Examples........................................19
5.13. WHISPER (new IRCX command)..........................19
5.13.1.Results.........................................19
5.13.2.Possible Errors.................................19
5.13.3.Remarks.........................................20
6. IRCX Server Messages.....................................20
6.1. AUTH (new IRCX message).............................20
6.1.1. Parameters......................................20
6.1.2. Remarks.........................................21
6.2. CLONE (new IRCX message)............................21
6.2.1. Parameters......................................21
6.2.2. Remarks.........................................21
6.2.3. Example.........................................21
6.3. CREATE (new IRCX message)...........................21
6.3.1. Parameters......................................21
6.3.2. Remarks.........................................22
6.3.3. Example.........................................22
6.4. DATA / REQUEST / REPLY (new IRCX messages)..........22
6.4.1. Parameters......................................22
6.4.2. Remarks.........................................22
6.5. EVENT (new IRCX message)............................23
6.5.1. Parameters......................................23
6.5.2. Example.........................................23
6.6. KNOCK (new IRCX message)............................23
6.6.1. Parameters......................................24
6.6.2. Remarks.........................................24
6.7. REDIRECT (new IRCX message).........................24
6.7.1. Parameters......................................24
6.7.2. Remarks.........................................24
6.7.3. Example.........................................24
6.8. WHISPER (new IRCX message)..........................24
6.8.1. Parameters......................................24
6.8.2. Remarks.........................................25
6.8.3. Example.........................................25
7. User Modes and Properties................................25
7.1. OWNER (IRCX +q).....................................25
7.2. GAG (IRCX +z).......................................25
8. Channel Modes and Properties.............................26
8.1. Modes...............................................26
8.1.1. PUBLIC (RFC1459 default)........................26
8.1.2. PRIVATE (RFC1459 +p)............................26
8.1.3. HIDDEN (IRCX +h)................................26
8.1.4. SECRET (RFC1459 +s).............................26
8.1.5. MODERATED (RFC1459 +m)..........................27
8.1.6. NOEXTERN (RFC1459 +n)...........................27
8.1.7. TOPICOP (RFC1459 +t)............................27
8.1.8. INVITE (RFC1459 +i).............................27
[Page 3]
INTERNET-DRAFT IRCX June 1998
8.1.9. KNOCK (IRCX +u).................................27
8.1.10.NOFORMAT (IRCX +f)..............................27
8.1.11.NOWHISPER (IRCX +w).............................28
8.1.12.AUDITORIUM (IRCX +x)............................28
8.1.13.REGISTERED (IRCX +r)............................28
8.1.14.SERVICE (IRCX +z)...............................28
8.1.15.AUTHONLY (IRCX +a)..............................29
8.1.16.CLONEABLE (IRCX +d).............................29
8.1.17.CLONE (IRCX +e).................................29
8.2. Properties..........................................30
8.2.1. OID (R/O).......................................30
8.2.2. NAME (R/O)......................................30
8.2.3. CREATION (R/O)..................................30
8.2.4. LANGUAGE........................................30
8.2.5. OWNERKEY........................................30
8.2.6. HOSTKEY.........................................31
8.2.7. MEMBERKEY.......................................31
8.2.8. PICS............................................31
8.2.9. TOPIC...........................................31
8.2.10.SUBJECT.........................................31
8.2.11.CLIENT..........................................31
8.2.12.ONJOIN..........................................32
8.2.13.ONPART..........................................32
8.2.14.LAG.............................................32
8.2.15.ACCOUNT.........................................32
8.2.16.CLIENTGUID......................................32
8.2.17.SERVICEPATH.....................................33
9. IRCX Command Responses...................................33
9.1. Command Replies.....................................33
9.2. IRCX Error Replies..................................36
10. Security Considerations..................................39
11. Acknowledgements.........................................40
12. References...............................................40
13. Authors' Addresses.......................................40
[Page 4]
INTERNET-DRAFT IRCX June 1998
3. Modified UTF8 Encoding of UNICODE characters
Allowing UNICODE characters for all user visible strings
introduces a set of compatibility problems if the protocol
must be backward compatible. UTF8 encoding is used to convert
wide UNICODE characters into a string compatible with existing
IRC servers and clients.
To permit the full range of UNICODE characters, we must
introduce an additional post-processing step on the result of
an UTF8 translation.
Any string beginning with a '%' character (i.e. "reason"
strings within a REDIRECT command) will be interpreted as
UTF8-encoded UNICODE strings.
UNICODE characters encoded in UTF8 may use more bytes than an
ASCII character. To ensure compatibility, UNICODE strings
such as nicknames and channel names must fit within the
standard length measured in bytes, not in characters.
The quoting character for the post-processing step is the '\'
character. All mappings are listed in the table below.
Table 1 - Character Quoting in UTF8
\b " " (blank)
\c ","
\\ "\"
\r CR
\n LF
\t TAB
IRCX clients view UTF8-encoded UNICODE strings in their native
form. So non-IRCX clients can inter-operate with UNICODE
nicks, UNICODE nicks are translated by the server into a
usable form before being sent to the non-IRCX client. This
usable format is a simple hex format preceded by a '^'
character. Non-IRCX clients can use this hex format nickname
to specify the IRCX/UNICODE user.
4. Terms and Definitions
Throughout this document we will use certain terms which are
defined in the following pages.
String lengths are indicated in "characters", referring to
ASCII characters, because even UNICODE strings must be encoded
in ASCII for the IRC protocol.
[Page 5]
INTERNET-DRAFT IRCX June 1998
Table 2 - Definition of Terms
Chat Network A Chat Network is comprised of one or more
servers linked together.
Server A server is a single machine.
Channel A channel (sometimes called a room or
conference) is a conversation between one or
more users.
Member A member is a user that is part of a
conversation in a channel.
User A user is a client that makes a connection to
the server.
Objects An object is a general term for channels,
users, members (users in a channel), and
servers. The type of object can be determined
from the first character of the object's name.
4.1. User Access Levels
There are six user levels that define the ability of the user
to perform operations. Some levels are determined on the
context of the operation to be performed.
Table 3 - Definition of Client Levels
Sysop Manager A Sysop Manager has full access to online
commands.
Sysop A Chat Sysop oversees and controls the chat
network.
Channel Owner A Channel Owner manages a channel and the
channel hosts.
Channel Host A Channel Host manages a channel. Also
referred to as a channel operator.
Channel Member A Channel Member is a member of a channel.
Chat User A Chat User is a client connected to the
server.
4.2. Prefixes
Each object contains a unique prefix that identifies the type
of object. By tagging UNICODE objects with a special prefix,
a client can easily decide whether to use standard ASCII or
UNICODE when sending a message to a user or channel. The IRCX
client is responsible, when sending a UNICODE string, for
[Page 6]
INTERNET-DRAFT IRCX June 1998
prefixing it with a '%' character so that other IRCX clients
can interpret it as UNICODE.
Table 4 - Object identifiers
# The '#' prefix identifies a RFC1459 global channel.
& The '&' prefix identifies a RFC1459 local channel.
%# The "%#" prefix identifies an extended global channel
name (a modified UTF8-encoded UNICODE string).
%& The "%&" prefix identifies an extended local channel
name (a modified UTF8-encoded UNICODE string).
% The '%' character followed by a space or comma can
identify the last channel that this client
specified and is a member of. Its function is to
optimize server processing of multiple messages from
a client to a channel.
A to } The 'A' through '}' prefix identifies a standard
RFC1459 nickname.
' The ''' prefix identifies an extended IRCX nickname
which consists of a modified UTF8-encoded UNICODE
string. The ''' character followed by a space or
comma is used to represent the local client
connection. The characters following ''' can be '0'
through '9', '-', and any character above 'A'.
^ The '^' prefix identifies a nickname which was
translated from UTF8 into hex characters so that the
nickname can be viewed by non-IRCX clients. The
characters following '^' can be any standard RFC1459
nickname characters.
0 The '0' prefix identifies an internal object
identifier (OID). The OID consists of the '0'
prefix and eight hexadecimal characters. If not
supported by the server, then OID must be returned as
'0'.
$ The '$' prefix identifies a server on the network.
The '$' character followed by a space or comma may
be used to represent the local server the client is
connected to.
5. IRCX Client Messages
This section details commands which have been added and
commands which have been changed from RFC1459. Responses from
the server are discussed in greater detail in later sections.
[Page 7]
INTERNET-DRAFT IRCX June 1998
5.1. ACCESS command (new IRCX command)
Create an "access entry" for an object to grant or deny access
to an object, including a channel, a user, or the server.
ACCESS LIST is used to list all access entries for an object
and CLEAR is used to clear all entries or all entries of the
same level.
Syntax 1: ACCESS <object> LIST
Syntax 2: ACCESS <object> ADD|DELETE <level> <mask>
[<timeout> [:<reason>]]
Syntax 3: ACCESS <object> CLEAR [<level>]
5.1.1. Parameters
<object> The object to which access is being granted or
limited. Can be a channel name, nickname, $ or *.
<level> The level of access being given or taken away. Can
be:
DENY Disallow access to an object that is accessible
GRANT Allow access to an object that is inaccessible
HOST Channel host access to specified channel
OWNER Channel owner access to specified channel
VOICE Voice access to specified channel
<mask> Mask to identify user by nickname, userid, host or
server characteristics. Supports wildcards * and ?.
<timeout> Minutes until the access entry is removed. A value
of 0 indicates unlimited duration.
<reason> Text reason shown when users are denied access due
to the access entry.
5.1.2. Results
IRCRPL_ACCESSADD
IRCRPL_ACCESSDELETE
IRCRPL_ACCESSSTART
IRCRPL_ACCESSLIST
IRCRPL_ACCESSEND
[Page 8]
INTERNET-DRAFT IRCX June 1998
5.1.3. Possible Errors
In this specification possible error messages are listed.
IRCERR_BADLEVEL
IRCERR_DUPACCESS
IRCERR_MISACCESS
IRCERR_TOOMANYACCESSES
IRCERR_TOOMANYARGUMENTS
IRCERR_BADCOMMAND
IRCERR_NOTSUPPORTED
IRCERR_NOACCESS
5.1.4. Remarks
An object with GRANT access entries but no DENY entries is
assumed to be off-limits to those users not covered by the
GRANT entries. If there are multiple entries in the access
list, the list is processed in the following order: OWNER,
HOST, VOICE, GRANT, DENY.
Hosts and Owners may add and delete access entries for their
channel. Hosts may not remove access entries added by owners.
Any user may add and delete access entries for themselves.
Sysops and sysop managers on a server may add and delete
access entries for that server or the entire network.
A user who has blocked another user does not get any messages
from the blocked user, including invites.
5.1.5. Examples
To make a user, "piper", a channel host when they join the
channel, "#mychan":
ACCESS #mychan ADD HOST piper
To grant normal access to the network to a few people but deny
access to all others:
ACCESS * ADD DENY * :closed for private party
ACCESS * ADD GRANT *.company.com :these people can get on
To delete the DENY access record on the network that denies
access to '*' (note that this doesn't delete other DENY access
records such as '*.com'):
[Page 9]
INTERNET-DRAFT IRCX June 1998
ACCESS * DELETE DENY *
To clear all DENY-level entries on the local server:
ACCESS $ CLEAR DENY
To clear all access entries of any level for a channel:
ACCESS #mychan CLEAR
5.2. AUTH Command (new IRCX command)
Authenticate the client using an SASL[4] authentication
mechanism.
Syntax 1: AUTH <name> <seq> [:<parameter>]
5.2.1. Parameters
<name> The name of the SASL mechanism to use for
authentication.
<seq> The sequence is a value of 'I' or 'S'. The 'I' value
is specified for the initial AUTH message and the 'S' value is
specified for all subsequent AUTH messages. If the
client specifies '*' for the sequence, the server will abort
the authentication sequence and return
IRCERR_AUTHENTICATIONFAILED.
<parameter> This is optional data sent as an argument with
the AUTH messages. The content depends on the authentication
mechanism being used. All content must use standard escaping
formats (e.g. \r for carriage return) to comply with IRC
message format restrictions.
5.2.2. Results
AUTH message
5.2.3. Possible Errors
ERR_NEEDMOREPARAMS
IRCERR_ALREADYAUTHENTICATED
IRCERR_ALREADYREGISTERED
IRCERR_AUTHENTICATIONFAILED
IRCERR_AUTHENTICATIONSUSPENDED
IRCERR_BADCOMMAND
IRCERR_UNKNOWNPACKAGE
[Page 10]
INTERNET-DRAFT IRCX June 1998
5.2.4. Remarks
If the server is known to support IRCX with specific SASL
mechanism(s), then the first message from an IRCX-compliant
client must be the AUTH command (if authentication is to be
used), before the USER and NICK commands. Use MODE ISIRCX to
determine if the server supports IRCX.
5.2.5. Example
Client: AUTH NTLM I :<data>
Server: AUTH NTLM S :<data>
Client: AUTH NTLM S :<data>
Server: AUTH NTLM * userid@domain 03FA4534C
5.3. CREATE (new IRCX command)
Create a new channel and/or join an existing channel.
Syntax: CREATE <channel> [<modes> [<modeargs>]]
5.3.1. Parameters
<channel> The name of the channel.
<modes> Initial channel modes, not separated by spaces (like
MODE command). Includes mode 'e' to force a clone of a
clonable channel.
<modeargs> Optional mode arguments, separated by spaces, in
the same order as the modes. For the mode 'l' the mode
argument is the maximum number of members in the channel.
For the mode 'k' the mode argument is the channel
keyword. These are the only modes that require mode
arguments.
5.3.2. Results
CREATE message
JOIN message
RPL_TOPIC
RPL_NAMEPLY
RPL_ENDOFNAMES
5.3.3. Possible Errors
IRCERR_CHANNELEXIST
[Page 11]
INTERNET-DRAFT IRCX June 1998
IRCERR_ALREADYONCHANNEL
ERR_NEEDMOREPARAMS
ERR_INVITEONLYCHAN
ERR_CHANNELISFULL
ERR_BANNEDFROMCHAN
ERR_BADCHANNELKEY
ERR_TOOMANYCHANNELS
ERR_UNKNOWNCOMMAND
5.3.4. Remarks
The CREATE command provides a method to specify channel
properties at creation time, and also provides a method (flag
'c') to create and join a channel only if it does not already
exist. If user is not in IRCX mode, server returns
ERR_UNKNOWNCOMMAND.
5.3.5. Examples
This example shows the creation of a moderated (m) channel
with the following properties and modes: its topic can only
be changed by an owner or host (t = TOPICOP), messages from
outside the channel are blocked (n = NOEXTERN), it is limited
to 50 members (l 50), it has a member key which is 'password'
(k password), and it will be created only if it doesn't
already exist (c = CREATE)
Client: CREATE #MyChannel tnmlkc 50 password
Server: CREATE #MyChannel 048532944
5.4. DATA / REQUEST / REPLY (new IRCX command)
Used to send tagged data, requests or replies. The syntax for
each is the same, but clients can use REQUEST to indicate that
a REPLY is desired, and use REPLY to indicate that a REQUEST
was issued. If user is not in IRCX mode, server returns
ERR_UNKNOWNCOMMAND.
Syntax 1: DATA <target> <tag> :<message>
5.4.1. Parameters
<target> The target for the data. Target can be a nick, list
of nicks, channel, list of channels, or channel followed
by a list of some members of the channel. This
[Page 12]
INTERNET-DRAFT IRCX June 1998
definition for <target> will be used throughout this
document.
<tag> Text field that clients use to know how to interpret
the data. Valid characters are [A..z], [0..9] and
period (.). The first character must be one of [A..z].
Maximum 15 characters. If the tag begins with ADM, SYS,
OWN or HST then the originator must have appropriate
privileges (Sysop Manager, Sysop, Channel Owner or
Channel Host. Channel Owner & Host apply to the channel
the message is being sent to.) The server itself can
send tags beginning with these reserved strings.
<message> Payload or data for the message, ending with a
newline. Any newlines or other control characters within
the body of the message must be escaped.
5.4.2. Results
DATA message
5.4.3. Possible Errors
ERR_UNKNOWNCOMMAND
5.4.4. Remarks
REPLY and REQUEST may be used to replace "DATA". IRCX servers
should not send DATA commands to clients that have not
indicated that they support IRCX. Clients should only process
DATA messages if they know and support the tag used.
Prefixes should indicate the organization that specified them,
when appropriate. For example: MYORG.AVATAR could be a tag
used by MyOrg, as would be all MYORG.* tags.
5.4.5. Example
Sending ad banners from server sysop to channel, "#Channel":
DATA #Channel SYS.AD.SMALL :<url-stuff>
5.5. EVENT (new IRCX command)
Add/Change/Delete event logging to the client connection. The
list of event types and the way masks are applied is not
specified here.
Syntax 1: EVENT [ADD | DELETE] <event> [<mask>]
Syntax 2: EVENT LIST [<event>]
5.5.1. Parameters
[Page 13]
INTERNET-DRAFT IRCX June 1998
<event> Type of event, such as CHANNEL, MEMBER, SERVER,
CONNECTION, SOCKET or USER.
<mask> Optional mask for applying a selection criteria per
event.
5.5.2. Results
IRCRPL_EVENTADD
IRCRPL_EVENTDEL
IRCRPL_EVENTSTART
IRCRPL_EVENTLIST
IRCRPL_EVENTEND
5.5.3. Possible Errors
ERR_NEEDMOREPARAMS
ERR_NOPRIVILEGES
IRCERR_BADFUNCTION
IRCERR_EVENTDUP
IRCERR_EVENTMIS
IRCERR_NOSUCHEVENT
IRCERR_TOOMANYEVENTS
5.5.4. Remarks
The EVENT command can be used by other server implementations
to define the events that a sysop manager or sysop of the
server wishes to be notified of. Only sysop managers and/or
sysops are allowed to receive event messages.
5.5.5. Examples
Add channel events.
Client: EVENT ADD CHANNEL
Server: :<host> 806 <nick> CHANNEL *!*@*$*
Add a list event with no active events returned.
Client: EVENT LIST
Server: :<host> 808 <nick> :Start of events
[Page 14]
INTERNET-DRAFT IRCX June 1998
:<host> 809 <nick> CHANNEL *!*@*$*
:<host> 810 <nick> :End of events
5.6. IRCX (new IRCX command)
Enables IRCX mode and displays IRCX status. Use MODE ISIRCX
first to see if the server supports IRCX.
Syntax: IRCX
5.6.1. Parameters
None.
5.6.2. Results
IRCRPL_IRCX
5.6.3. Example
This example includes a server that supports IRCX and three
authentication packages.
Client: IRCX
Server: :<host> 800 <nick> 1 0 NTLM,DPA,ANON 512 *
5.7. ISIRCX (new IRCX command)
Queries whether or not the server supports the Extended
RFC1459 protocol (IRCX). Server response is same as for IRCX
message.
Use ISIRCX after logging into the server.
Syntax: ISIRCX
5.7.1. Results
IRCRPL_IRCX
5.8. LISTX (new IRCX command)
Extended version of the LIST command that returns additional
channel properties. Channels with extended names will be
returned, even to non-IRCX clients. Some channel modes and
the PICS rating string are included with the result. Only the
channel modes that do not define an additional argument
(TOPICOP, NOEXTERN, etc.) are included in the <modes> field.
Clients should use the query limit to avoid overloading the
client or having the connection dropped by the server.
Syntax 1: LISTX [<channel list>]
[Page 15]
INTERNET-DRAFT IRCX June 1998
Syntax 2: LISTX <query list> [<query limit>]
5.8.1. Parameters
<channel list> A list of channels may be specified in order
to find the PICS ratings or modes of those channels. If
no channels are specified, the server will send the
entire matching list of channels.
<query list> One or more query terms separated by spaces or
commas.
Table 5 - Query terms for LIST command
<# Select channels with less than # members.
># Select channels with more than # members.
C<# Select channels created less than # minutes
ago.
C># Select channels created greater than # minutes
ago.
L=<mask> Select channels with language property
matching the mask string.
N=<mask> Select channels with name matching the mask
string.
R=0 Select unregistered channels.
R=1 Select registered channels.
S=<mask> Select channels with subject matching the mask
string.
T<# Select channels with a topic changed less than
# minutes ago.
T># Select channels with a topic changed greater
than # minutes ago.
T=<mask> Select channels that topic matches the mask
string.
<query limit> Maximum number of channels to be returned.
<mask> Sequence of characters that is used to select
a matching channel name or topic. The
character * and ? are used for wildcard
searches.
5.8.2. Results
[Page 16]
INTERNET-DRAFT IRCX June 1998
IRCRPL_LISTXSTART
IRCRPL_LISTXLIST
IRCRPL_LISTXPICS
IRCRPL_LISTXTRUNC
IRCRPL_LISTXEND
5.8.3. Remarks
To compose a mask, use this character escaping scheme.
Table 6 - Character escaping in mask-string
\b for " " blank
\c for ","
\\ for "\"
\* for *
\? for ?
The PICS property is only returned if not null.
A record limit of '0' (zero) or blank will be interpreted as
unlimited.
5.9. MODE (extension to RFC1459 command)
MODE command can now be used for new user or channel modes
(see later sections). In addition, the special syntax "MODE
ISIRCX" can be used to help clients find out whether a server
supports IRCX prior to logging into the server.
Syntax: MODE ISIRCX
5.9.1. Results
MODE message
IRCRPL_IRCX
5.9.2. Remarks
The ISIRCX mode (must be in capital letters) is only
functional before the user has registered with the server.
IRCX servers respond with IRCRPL_IRCX and non-IRCX servers
should return an error code. This allows unregistered users
to query whether the server supports IRCX.
[Page 17]
INTERNET-DRAFT IRCX June 1998
See RFC1459 for more details on the original MODE command and
its parameters.
5.10. NOTICE (extension to RFC1459 command)
Sends a notice to a channel or user. In RFC1459 a notice
could only be sent to a channel or a list of users. Now a
notice can be sent to a list of users within the context of a
channel. As before, users will not get the list of users that
received the notice.
Syntax: NOTICE <target> :<message>
5.10.1. Results
Same as defined in RFC1459, but with the additional
functionality of sending to a list of nicknames within the
context of a channel.
5.11. PRIVMSG (extension to RFC1459 command)
Sends a message to a channel or user. PRIVMSG is extended in
the same way as NOTICE.
Syntax: PRIVMSG <target> :<message>
5.11.1. Results
Same as defined in RFC1459, but with the additional
functionality of sending to a list of nicknames within the
context of a channel.
5.12. PROP (new IRCX command)
Add, change or delete a channel data property.
To query a property:
Syntax 1: PROP <channel> <property>[,<property>]
To set or change a property:
Syntax 2: PROP <channel> <property> :<data>
To delete a property:
Syntax 3: PROP <channel> <property> :
5.12.1. Results
PROP message
IRCRPL_PROPLIST
[Page 18]
INTERNET-DRAFT IRCX June 1998
IRCRPL_PROPEND
5.12.2. Possible Errors
IRCERR_BADCOMMAND
IRCERR_BADPROPERTY
IRCERR_SECURITY
IRCERR_NOSUCHOBJECT
IRCERR_TOOMANYARGUMENTS
IRCERR_BADVALUE
5.12.3. Remarks
The PROP command provides a new method for manipulating string
and numeric properties of channels. If an optional channel
property is not supported on the server, the server should
return IRCERR_BADPROPERTY.
See section 8.2 for definitions of channel properties.
5.12.4. Examples
Client: PROP #MyChan TOPIC,ONJOIN
Server: :<host> 818 <nick> #MyChan TOPIC :This is the topic of
my channel
Server: :<host> 818 <nick> #MyChan ONJOIN :Welcome to my
channel!
Server: :<host> 819 <nick> #MyChan :End of properties
Client: PROP #MyChannel TOPIC :Change my channel topic
Server: PROP #MyChannel TOPIC :Change my channel topic
5.13. WHISPER (new IRCX command)
Whisper to member(s) in a channel.
Syntax: WHISPER <channel> <nick-list> :<message>
5.13.1. Results
WHISPER message
5.13.2. Possible Errors
[Page 19]
INTERNET-DRAFT IRCX June 1998
ERR_UNKNOWNCOMMAND
ERR_CANNOTSENDTOCHAN
ERR_USERNOTINCHANNEL
ERR_NEEDMOREPARAMS
IRCERR_NOTONCHANNEL
IRCERR_TOOMANYTARGETS
IRCERR_NOSUCHNICK
IRCERR_NOSUCHCHANNEL
IRCERR_NOWHISPER
5.13.3. Remarks
The purpose of the WHISPER command is to whisper to one or
more members in a channel within the context of that channel.
The sender and all recipients must be in the channel
specified. A whisper is different from a privmsg in that it
includes both a user list and a channel name, indicating that
the message is private but has a context.
IRCX clients should display the WHISPER message within the
context (possibly a window) of the specified channel. Non-
IRCX clients receive a PRIVMSG with the content of the whisper
(losing the context of the whisper). Only one whisper will be
sent per nick. A user may whisper to themselves.
The channel mode 'w' will disable whispers between ordinary
members of the channel (but not whispers from or to channel
operators).
6. IRCX Server Messages
This section summarizes new extended messages which can be
sent from the server.
6.1. AUTH (new IRCX message)
Negotiates authentication with client or informs client that
authorization was successful.
Syntax 1 (negotiating authorization): AUTH <name> S
[:<parameter>]
Syntax 2 (authorization successful): AUTH <name> * <ident>
<oid>
6.1.1. Parameters
[Page 20]
INTERNET-DRAFT IRCX June 1998
<name> The name of the SASL mechanism to use for
authentication.
<ident> The ident is the userid@domain of the authenticated
client account. It is returned on the final response from the
server (Syntax 2) when authentication is successful.
<oid> The OID is the internal object identifier assigned to
the client connection. If not supported by the server, then
OID must be returned as '0'.
<parameter> This is optional data sent as an argument with
the AUTH messages.
6.1.2. Remarks
The server will send the syntax 2 form when the authentication
process is complete or a numeric error reply.
6.2. CLONE (new IRCX message)
Informs the hosts and owners in a CLONEABLE channel that a
new CLONE channel was created.
Syntax: CLONE <channel-name> <oid>
6.2.1. Parameters
<channel-name> The name of the created CLONE channel.
<oid> The object identifier for this new CLONE channel. The
value is implementation-dependent and must equal 0 if not
supported.
6.2.2. Remarks
The CLONE message can be sent at anytime to the hosts/owners
of a CLONEABLE channel to inform them that a new CLONE channel
was created. This message is intended to be used by a custom
application to automatically join the new CLONE channel. A
non-IRCX client will not get this message.
6.2.3. Example
Server: CLONE #MyChat1 034F8FF32
6.3. CREATE (new IRCX message)
Informs the client that a new channel was created. Response
to the CREATE command.
Syntax: CREATE <channel-name> <oid>
6.3.1. Parameters
[Page 21]
INTERNET-DRAFT IRCX June 1998
<channel-name> The name of the created channel.
<oid> The object identifier for this new channel. The value
is implementation- dependent and must equal 0 if not
supported.
6.3.2. Remarks
The CREATE message is sent in response to a CREATE command
sent by the client application if the channel specified did
not previously exist and was created by the server.
6.3.3. Example
Server: CREATE #MyChat1 034F8FF32
6.4. DATA / REQUEST / REPLY (new IRCX messages)
The DATA message (could be REQUEST or REPLY also) is
forwarded from another user or sent by the server. The
payload or message should be interpreted according to the tag.
If the tag is unknown, the message may be discarded.
Syntax 1: <sender> :DATA <target> <tag> :<message>
<sender> :REQUEST <target> <tag> :<message>
<sender> :REPLY <target> <tag> :<message>
If the DATA, REQUEST or REPLY message is sent to a number of
members within a channel, the receiving user will see the
channel name and their own nick in the message as follows:
Syntax 2: <sender> :DATA <channel> <nick> <tag> :<message>
6.4.1. Parameters
<sender> May be a user or a server.
<target> Channel and/or nick list as defined above.
<tag> Identifying tag.
<message> Payload.
6.4.2. Remarks
The tag indicates what to do with the message. Tag types may
be specified by administrators, client developers, server
developers etc.
A tag beginning with SYS can only be from a sysop, sysop
manager or the server. A tag beginning with ADM can only be
from a sysop manager or the server.
[Page 22]
INTERNET-DRAFT IRCX June 1998
DATA message functionality is different from client-to-client
messaging in several respects. First, we encourage groups to
define their own tags and data formats for special purposes,
for example to indicate details for a user's avatar in
graphical chats, or to indicate that an ad banner or image
should be downloaded. Second, the DATA message is more
appropriate for content that may go to several users, for
example all users in a channel. Third, the DATA message may
come from the server. Fourth, the SYS and ADM prefixes are
specified so that important tags may be reserved for sysops,
sysop managers and the server itself, with the server
responsible for verifying the sender before forwarding the
DATA message.
6.5. EVENT (new IRCX message)
Notifies the client of an event. These events are intended
for sysops and sysop managers, and are sent in addition to IRC
events.
Syntax: EVENT <time-stamp> <object> <event type> <parameters>
6.5.1. Parameters
<time-stamp> The number of elapsed seconds from midnight
(00:00:00) January 1, 1970 (coordinated universal time) until
the time that the event occurred on the server.
<object> Objects can be Channel, Member, User, Connection,
Socket or Server.
<event type> Event type varies depending on the object. For
example, events for channels can be Create, Destroy, Topic
change, Mode change, Collision.
<parameters> Vary depending on event type.
6.5.2. Example
This example is the event generated when a user logs onto
server, "chat1" with the nickname, "john", showing the user's
info including IP address and port.
EVENT chat1 946080000 USER LOGON john!jsmith@uw.edu
192.29.93.93:1111
6.6. KNOCK (new IRCX message)
Informs the owners and hosts of a channel that a user has
tried to enter the channel and could not (could be because of
a full channel, keyword wrong, user ban, or other reasons).
This message is only sent to the IRCX owners and hosts of the
channel.
[Page 23]
INTERNET-DRAFT IRCX June 1998
Syntax: <user> KNOCK <channel> <reason>
6.6.1. Parameters
<user> User field is of the format nick!userid@host.
<channel> Name of the channel that the user tried to enter.
<reason> Reason that the user received when they tried to
join the channel.
6.6.2. Remarks
A KNOCK message will not be sent to a non-IRCX client.
6.7. REDIRECT (new IRCX message)
Informs the client that they need to connect to another
server.
Syntax: REDIRECT <server-list> :<reason>
6.7.1. Parameters
<server-list> The server list is a comma separated list of
host:port pairs. The server list can be specified either as
a fully-qualified domain name or by the IP address in quad-
dotted notation.
<reason> The redirect reason is an implementation-dependent
string which can optionally be displayed to the client.
6.7.2. Remarks
The REDIRECT message can be sent to the client at any time to
request that the client disconnect and reconnect to another
server specified in the list. The REDIRECT message is
generally sent when a server is to be shutdown.
A REDIRECT message will not be sent to a non-IRCX client.
6.7.3. Example
Server: REDIRECT chat.corp.net:6667,134.9.3.3:6667 :Server
full.
6.8. WHISPER (new IRCX message)
A whisper from another channel member.
Syntax: <sender> WHISPER <channel> <nick list> :<text>
6.8.1. Parameters
[Page 24]
INTERNET-DRAFT IRCX June 1998
<sender> The nick-name of the person that sent the whisper.
<channel> The channel that the message is sent to.
<nick list> The list of nicknames of channel members that will
receive the whisper.
<text> The content of the whisper.
6.8.2. Remarks
The server may transform a WHISPER into a PRIVMSG for clients
that do not support IRCX.
6.8.3. Example
Server: Joe WHISPER #test Jill :Test whisper.
7. User Modes and Properties
These are new user modes and properties that have been added.
The MODE command as defined in RFC1459 is used to add or
remove modes.
7.1. OWNER (IRCX +q)
The OWNER mode indicates that the user is an owner of a
channel. Only a channel owner can give OWNER mode to another
member of that channel, but any owner may remove OWNER mode
from themselves.
Clients in IRCX mode see owner nicknames with a '.' prefix
and continue to see hosts with a '@' prefix (in results
from NAMES, WHO, WHOIS and other commands which list
nicknames).
Note that HOST mode uses +o, which was "operator" mode in
RFC1459. Syntax for these modes is the same as "operator"
mode:
MODE <channel> { + | - }q <nick>
7.2. GAG (IRCX +z)
The GAG mode is applied by a sysop or sysop manager on a user
and may not be removed except by a sysop or sysop manager.
The user may not be notified when this mode is applied because
the mode can be a more effective tool for keeping order if the
user doesn't know exactly when it is applied.
The server will discard all messages from a user with GAG mode
to any other user or to any channel.
MODE <nick> { + | - }z
[Page 25]
INTERNET-DRAFT IRCX June 1998
8. Channel Modes and Properties
New modes and properties have been added to channels.
Channels support four mutually exclusive states of visibility:
public, private, hidden, and secret. The visibility of a
channel affects which modes and properties are available to a
client.
8.1. Modes
Each channel object contains a number of binary mode settings
that can be queried and optionally updated via the RFC1459
MODE command.
8.1.1. PUBLIC (RFC1459 default)
The channel is public and all information about the channel
(except for text messages) can be queried by non-members.
PUBLIC mode is mutually exclusive with the PRIVATE, HIDDEN and
SECRET modes.
This mode may be set and queried by sysop managers, owners and
hosts of the channel. It may be queried by sysops, members of
the channel, and users.
8.1.2. PRIVATE (RFC1459 +p)
The channel is private and only the name, number of members
and PICS property can be queried by non-members. PRIVATE
mode is mutually exclusive with the PUBLIC, HIDDEN and SECRET
modes.
This mode may be set by sysop managers, owners and hosts of
the channel. It may be not be queried by sysops or users.
8.1.3. HIDDEN (IRCX +h)
The channel is hidden and cannot be located by enumeration
queries from non-members. HIDDEN mode is mutually exclusive
with the PUBLIC, PRIVATE, and SECRET modes. The purpose of
the new HIDDEN channel mode is to permit the existence of
channels that cannot be found using the standard LIST
command, but whose properties can be queried if the exact
channel name is known. Thus a HIDDEN channel is the same as
a PUBLIC channel except that it cannot be enumerated by using
a LIST or LISTX command.
This mode may be set and queried like PUBLIC mode.
8.1.4. SECRET (RFC1459 +s)
[Page 26]
INTERNET-DRAFT IRCX June 1998
The channel is secret and cannot by located by any query from
non-members. SECRET mode is mutually exclusive with the
PUBLIC, PRIVATE, and HIDDEN modes.
This mode may be set and queried like PRIVATE mode.
8.1.5. MODERATED (RFC1459 +m)
Normally, new channel members may speak. In MODERATED mode
however, new channel members may not speak by default. This
is achieved by giving all new members the '-v' mode (no voice)
for that channel. Usually -v mode has no effect, but in a
MODERATED channel it does.
This mode may be set and queried by sysop managers, owners and
hosts of the channel. It may be queried by sysops and members
of the channel. Users may query this mode if the channel is
PUBLIC or HIDDEN.
8.1.6. NOEXTERN (RFC1459 +n)
NOEXTERN mode blocks messages from non-members to the
channel. A sysop manager can still send a message to the
channel.
This mode may be set and queried like MODERATED mode.
8.1.7. TOPICOP (RFC1459 +t)
TOPICOP mode permits only channel owners and hosts to change
the channel topic property.
This mode may be set and queried like MODERATED mode.
8.1.8. INVITE (RFC1459 +i)
INVITE mode permits only invited users to enter the channel.
Only owners and hosts can issue an invitation when this mode
is on.
This mode may be set and queried like MODERATED mode.
8.1.9. KNOCK (IRCX +u)
The KNOCK extended mode causes a KNOCK message to be sent to
owners and hosts of the channel if a user attempts to join a
channel and the server denies entrance.
This mode may be set and queried like MODERATED mode.
8.1.10. NOFORMAT (IRCX +f)
The NOFORMAT channel mode is an indication to the client
application not to format text received from the channel.
[Page 27]
INTERNET-DRAFT IRCX June 1998
Normally clients will prefix text messages with "x said y" or
"x whispers to y and x", if the NOFORMAT mode is set then
just the raw text should be displayed moving to the next line
at the end of the message. The client should not echo text
sent by the client. This is to permit custom applications to
control the formatting to clients. Clients may want to inform
users that messages can be spoofed with this mode.
This mode can only be set by sysop managers. It can be read
by sysop managers, sysops, owners, hosts and members of the
channel. It can be read by users if the channel is PUBLIC or
HIDDEN.
8.1.11. NOWHISPER (IRCX +w)
The NOWHISPER channel mode will prevent all messages sent to
specific nicknames within the context of that channel.
This channel mode may be set and read by sysop managers and
owners. It can be read by sysops, hosts and members of the
channel. It can be read by other users if the channel is
PUBLIC or HIDDEN.
8.1.12. AUDITORIUM (IRCX +x)
The AUDITORIUM channel mode restricts visibility and messaging
within a channel. Members will only see themselves and the
hosts/owners in the channel. Any message sent by a member
will only be received by the hosts and owners. Hosts and
owners will see all members in the channel and messages from a
host or owner are seen by all channel members. Ordinary
members will not receive JOIN/PART messages from other
members. This mode is designed for channels with so many
members that they do not want to see each other. Note that
auditorium mode may only be set at channel creation time using
the CREATE command.
This mode may be set and read by sysop managers, sysops, and
owners. It may be read by hosts and members of the channel.
It can be read by other users if the channel is PUBLIC or
HIDDEN.
8.1.13. REGISTERED (IRCX +r)
The channel is registered by the administrator of the chat
network. The registration procedure is not defined here. Only
the server or server administrator can set this mode.
It can be read by sysop managers, sysops, owners, hosts, and
members of the channel. It can be read by users if the
channel is PUBLIC or HIDDEN.
8.1.14. SERVICE (IRCX +z)
[Page 28]
INTERNET-DRAFT IRCX June 1998
A service is monitoring/controlling the channel. This is an
indication to the client that message traffic sent to the
channel is being monitored by a Chat Service which does not
appear as a member in the channel.
This mode can only be set by the Chat Server. It can be read
by sysop managers, sysops, owners, hosts and members of the
channel. It can be read by users if the channel is PUBLIC or
HIDDEN.
8.1.15. AUTHONLY (IRCX +a)
The AUTHONLY channel mode permits channel access only to users
who have been authenticated by the server. Note that an
authenticated user is any user that was successfully
authenticated with the PASS command or the AUTH command.
This mode can be set and read by sysop managers or owners of
the channel. It can be read by sysops, hosts and members of
the channel. It can be read by users if the channel is PUBLIC
or HIDDEN.
8.1.16. CLONEABLE (IRCX +d)
The CLONEABLE channel mode defines a channel that creates new
clone channels if the parent channel is full. A clone channel
is created with the same name as the parent cloneable channel
with a numeric suffix starting at 1, ranging to 99. It is not
valid to set the CLONEABLE channel mode of a parent channel
that ends with a numeric character. The clone channel
inherits modes and properties from the parent channel when it
is set up. When a clone channel is created, any channel that
has the same name is removed. This prevents channel takeover
of a clone channel.
It is advised that only sysop be allowed to set cloneable mode
on a channel. The mode may be read by sysops, owners, hosts
and members of the channel. It may be read by users if the
channel is PUBLIC or HIDDEN.
8.1.17. CLONE (IRCX +e)
The CLONE channel mode defines a channel that was created by
the server when a parent CLONEABLE channel becomes full.
Users should usually join the parent channel, although a user
may join a clone channel that is not full. A sysop manager
can set up a clone channel but only when the channel is being
created.
This mode can be set by the sysop manager and read like the
SERVICE mode.
[Page 29]
INTERNET-DRAFT IRCX June 1998
8.2. Properties
Each channel object contains a number of properties that can
be queried and optionally updated via the IRCX PROP command.
Owners and hosts may update a property for their own channel.
Sysop Managers and Sysops can use the PROP command on a
channel only by becoming host/owner of that channel. Users
and members can read properties only.
8.2.1. OID (R/O)
The OID channel property is the internal object identifier for
the channel. As a shortcut, the OID can be optionally used
in place of the full string name of a channel. If the OID
is set to "0", then this feature is not supported on the
server.
This property may be read by all users, except by ordinary
users when the channel is SECRET or PRIVATE.
8.2.2. NAME (R/O)
The NAME channel property is the name of the channel (limited
to 63 characters, including 1 or 2 characters for channel
prefix). Valid characters are as defined in RFC1459.
This property may be set and read like the OID property.
8.2.3. CREATION (R/O)
The CREATION channel property is the time that the channel
was created, in number of seconds elapsed since midnight
(00:00:00), January 1, 1970, (coordinated universal time).
This property may be set and read like the OID property.
8.2.4. LANGUAGE
The LANGUAGE channel property is the preferred language type.
The LANGUAGE property is a string limited to 31 characters.
We recommend following the guidelines of RFC1766[6] to form
well-understood language-defining strings.
This property may be set and read by sysop managers, owners
and hosts of the channel. It may be read by sysop managers,
sysops and members. It may be read by users if the channel is
PUBLIC or HIDDEN.
8.2.5. OWNERKEY
The OWNERKEY channel property is the owner keyword that will
provide owner access when entering the channel. The OWNERKEY
property is limited to 31 characters.
[Page 30]
INTERNET-DRAFT IRCX June 1998
This property may be set by the sysop manager or channel
owner. It may never be read.
8.2.6. HOSTKEY
The HOSTKEY channel property is the host keyword that will
provide host (channel op) access when entering the channel.
The HOSTKEY property is limited to 31 characters.
This property may be set and read like the OWNERKEY property.
8.2.7. MEMBERKEY
The MEMBERKEY channel property is the keyword required to
enter the channel. The MEMBERKEY property is limited to 31
characters. This is backwards-compatible with RFC1459 because
users can still use the MODE command as an alternative way to
set this property.
This property may be set and read like the OWNERKEY property.
8.2.8. PICS
The PICS channel property is the current PICS rating of the
channel. Chat clients that are PICS enabled can use this
property to determine if the channel is appropriate for the
user. The PICS property is limited to 255 characters. The
format for this field is defined by PICS (see
http://www.w3.org).
This property may be set by sysop managers and read by all.
It may not be read by ordinary users if the channel is SECRET.
8.2.9. TOPIC
The TOPIC channel property is the current topic of the
channel. The TOPIC property is limited to 160 characters.
This property may be set and read by sysop managers, owners
and hosts of the channel. It may be read by sysops and
members of the channel. It may be read by users if the
channel is PUBLIC or HIDDEN.
8.2.10. SUBJECT
The SUBJECT channel property is a string that can contain
subject keywords for search engines. The SUBJECT property is
limited to 31 characters.
This property may be set and read like the TOPIC property.
8.2.11. CLIENT
[Page 31]
INTERNET-DRAFT IRCX June 1998
The CLIENT channel property contains client-specified
information. The format is not defined by the server. The
CLIENT property is limited to 255 characters.
This property may be set and read like the TOPIC property.
8.2.12. ONJOIN
The ONJOIN channel property contains a string to be sent (via
PRIVMSG) to a user after the user has joined the channel. The
channel name is displayed as the sender of the message. Only
the user joining the channel will see this message. Multiple
lines can be generated by embedding '\n' in the string. The
ONJOIN property is limited to 255 characters.
This property may be set and read by sysop managers, owners
and hosts of the channel. It may additionally be read by
sysops.
8.2.13. ONPART
The ONPART channel property contains a string that is sent
(via NOTICE) to a user after they have parted from the
channel. The channel name is displayed as the sender of the
message. Only the user parting the channel will see this
message. Multiple lines can be generated by embedding '\n'
in the string. The ONPART property is limited to 255
characters.
This property may be set and read like the ONJOIN property.
8.2.14. LAG
The LAG channel property contains a numeric value between 0 to
2 seconds. The server will add an artificial delay of that
length between subsequent messages from the same member. All
messages to the channel are affected.
This property may be set and read by sysop managers and
owners. It can additionally be read by sysops, hosts, and
members of the channel. It can be read by users if the
channel is PUBLIC or HIDDEN.
8.2.15. ACCOUNT
The ACCOUNT channel property contains an implementation-
dependent string for attaching a security account. This
controls access to the channel using the native OS security
system. The ACCOUNT property is limited to 31 characters.
This property may be set by sysop managers. It can only be
read by sysop managers, sysops and owners of the channel.
8.2.16. CLIENTGUID
[Page 32]
INTERNET-DRAFT IRCX June 1998
The CLIENTGUID channel property contains a GUID that defines
the client protocol to be used within the channel.
This property may be set and read like the LAG property.
8.2.17. SERVICEPATH
The SERVICEPATH channel property contains the path of a server
side extension that is used to control the channel operation.
Details are implementation-dependent.
This property may be set and read like the LAG property.
9. IRCX Command Responses
The new extended IRCX numeric replies follow the same
convention as IRC replies, with a specific range for command
responses and another range for error results. The IRCX
command responses are in the range of 800 to 899 and 900 to
999 for the error results.
9.1. Command Replies
800 - IRCRPL_IRCX
<state> <version> <package-list> <maxmsg> <option-list>
The response to the IRCX and ISIRCX commands. The <state>
indicates if the client has IRCX mode enabled (0 for disabled,
1 for enabled). The <version> is the version of the IRCX
protocol starting at 0. The <package-list> contains a list
of authentication packages supported by the server. The
package name of "ANON" is reserved to indicate that anonymous
connections are permitted. The <maxmsg> defines the maximum
message size permitted, with the standard being 512. The
<option-list> contains a list of options supported by the
server; these are implementation-dependent. If no options are
available, the '*' character is used.
801 - IRCRPL_ACCESSADD
<object> <level> <mask> <timeout> <user> :<reason>
Response to a successful ACCESS ADD command. The <object> is
the name of the object to which the access restrictions apply
(i.e. channel name or user name). The <level> is the level of
access being added (i.e. GRANT, DENY). The <mask> is the
selection mask. If no mask is provided in the ACCESS command,
then the default mask of *!*@*$* is used. The <timeout> is
the amount of time this access entry will last. The <user> is
the one who added the new ACCESS record. The <reason> is the
reason supplied in the ACCESS ADD command.
802 - IRCRPL_ACCESSDELETE
[Page 33]
INTERNET-DRAFT IRCX June 1998
<object> <level> <mask>
Response to a successful ACCESS DELETE command. See reply
801 for explanation of the fields.
803 - IRCRPL_ACCESSSTART
<object> :Start of access entries
Beginning of a list of access entries. <object> is the object
to which the access restrictions apply (i.e. channel name or
user name). The next message will be an IRCRPL_ACCESSLIST or
IRCRPL_ACCESSEND reply.
804 - IRCRPL_ACCESSLIST
<object> <level> <mask> <timeout> <user> :<reason>
One entry in a list of access entries. See reply 801 for
explanation of the fields.
805 - IRCRPL_ACCESSEND
<object> :End of access entries
End of a list of access entries. See reply 803 for explanation
of the field. This reply will always follow an
IRCRPL_ACCESSSTART or IRCRPL_ACCESSLIST reply.
806 - IRCRPL_EVENTADD
<event> <mask>
The acknowledgment response to the EVENT ADD command. The
<event> contains the name of the event added. The <mask> is
the selection mask. If no mask is provided in the EVENT
command, then the default mask of *!*@*$* is used.
807 - IRCRPL_EVENTDEL
<event> <mask>
The acknowledgment response to the EVENT DELETE command. The
<event> contains the name of the deleted event. The <mask> is
the selection mask. If no mask is provided in the EVENT
command, then the default mask of *!*@*$* is used.
808 - IRCRPL_EVENTSTART
:Start of events
Response to the EVENT LIST <event> message that indicates the
start of the event list.
[Page 34]
INTERNET-DRAFT IRCX June 1998
809 - IRCRPL_EVENTLIST
<event> <mask>
Response to the EVENT LIST <event> message that displays a
list of current events that the client is interested in.
810 - IRCRPL_EVENTEND
:End of events
Response to the EVENT LIST <event> message that indicates the
end of the event list.
811 - IRCRPL_LISTXSTART
:Start of ListX
First reply to a LISTX (extended list) command. Will always
be followed by a reply of type 812, 816 or 817.
812 - IRCRPL_LISTXLIST
<channel> <modes> <members> <member limit> :<topic>
Single list item in an extended list of channels. The
<channel> is the name of the channel in the list. The <modes>
specify the current modes set on the channel. <members> lists
the members currently in the channel. <member limit> returns
the member limit of the channel. <topic> returns the topic of
the channel.
813 - IRCRPL_LISTXPICS
:<PICS-rating>
PICS rating string for the last channel listed (follows an 812
message).
816 - IRCRPL_LISTXTRUNC
:Truncation of ListX
Last reply to a LISTX command, either because the user asked
for a limited list of channels or because the server truncated
the list to prevent output flooding. Always follows a reply
of type 811, 812 or 813.
817 - IRCRPL_LISTXEND
:End of ListX
Last reply to a LISTX command, indicating that the list has
ended. Always follows a reply of type 811, 812 or 813.
[Page 35]
INTERNET-DRAFT IRCX June 1998
818 - IRCRPL_PROPLIST
<object> <property> :<value>
A value in a property list. The <object> is the name of the
object (i.e., channel name). The <property> is the property
in the list. The <value> is the value of the property listed.
819 - IRCRPL_PROPEND
<object> :End of properties
Last message in a property list.
9.2. IRCX Error Replies.
900 - IRCERR_BADCOMMAND
<command> :Bad command
Response to an incorrectly formatted command.
901 - IRCERR_TOOMANYARGUMENTS
<command> :Too many arguments
Response to too many arguments being provided for a command.
902 - IRCERR_BADFUNCTION
<command> :Bad function
Response to a command that supports functions, with invalid
function sent by the user. For example, the EVENT command
supports functions.
903 - IRCERR_BADLEVEL
<command> :Bad level
Response to an ACCESS command with a bad level specified (i.e.
not GRANT, DENY...)
904 - IRCERR_BADTAG
<command> :Bad message tag.
Response to a DATA/REQUEST/REPLY with an incorrect message
tag.
905 - IRCERR_BADPROPERTY
<channel> :Bad property specified
[Page 36]
INTERNET-DRAFT IRCX June 1998
Response to a channel property command with a bad property
specified.
906 - IRCERR_BADVALUE
<channel> :Bad value specified
Response to an attempt to set an integer property to a string
value (PROP command).
907 - IRCERR_RESOURCE
:Not enough resources
Server does not have enough resources to perform command.
908 - IRCERR_SECURITY
:No permissions to perform command
For security reasons, the command/function/operation is not
permitted for this level of client.
909 - IRCERR_ALREADYAUTHENTICATED
<package> :Already authenticated
The client is already authenticated with the server.
910 - IRCERR_AUTHENTICATIONFAILED
<package> :Authentication failed
The authentication failed due to a bad userid/password or
server/network failure.
911 - IRCERR_AUTHENTICATIONSUSPENDED
<package> :Authentication suspended for this IP
Authentication has been temporary disabled due to too many
authentication failures from this IP.
912 - IRCERR_UNKNOWNPACKAGE
<package> :Unsupported authentication package
The authentication package specified is not known to the
server. ISIRCX command will return a list of supported
authentication packages.
913 - IRCERR_NOACCESS
<command> :No access
[Page 37]
INTERNET-DRAFT IRCX June 1998
Response to a user trying to change the ACCESS list for an
object the user does not have sufficient privileges to alter.
914 - IRCERR_DUPACCESS
:Duplicate access entry
An access entry already exists for the specified user mask.
915 - IRCERR_MISACCESS
:Unknown access entry
Response to ACCESS DELETE command when server does not
recognize the entry to be removed.
916 - IRCERR_TOOMANYACCESSES
:Too many access entries
Response to ACCESS ADD command when maximum number of access
entries has been reached.
918 - IRCERR_EVENTDUP
<event> <mask> :Duplicate event entry
The user has asked for an event that is already being sent.
919 - IRCERR_EVENTMIS
<event> <mask> :Unknown event entry
Response to event remove command when user is not already
receiving the event specified.
920 - IRCERR_NOSUCHEVENT
<event> :No such event type
Response to event add command when server does not recognize
the event specified.
921 - IRCERR_TOOMANYEVENTS
<event> :Too many events specified
Response to event add command when user may not add another
event to monitor.
923 - IRCERR_NOWHISPER
<object> :Does not permit whispers
[Page 38]
INTERNET-DRAFT IRCX June 1998
Response to whisper command when channel does not permit
whispers.
924 - IRCERR_NOSUCHOBJECT
<object> :No such object found
Response to an attempt to define a property for an object
which can't be found (PROP command).
925 - IRCERR_NOTSUPPORTED
<object> :Command not supported by object
Response to PROP and ACCESS commands when a bad object was
specified in the command.
926 - IRCERR_CHANNELEXIST
<channel> :Channel already exists.
The channel name in the CREATE command already exists on the
server and the +c mode was specified.
927 - IRCERR_ALREADYONCHANNEL
<channel> :Already in the channel.
Response to join command when user is already in the channel.
999 - IRCERR_UNKNOWNERROR
:Unknown error code <error-code>
The internal error generated doesn't map to a valid IRCX error
reply. The error code is implementation-dependent.
10. Security Considerations
Security issues are also discussed in the authentication
section.
The IRCX and ISIRCX commands return a set of authentication
mechanisms supported by the server. This method is open to a
middle man attack whereby an attacker modifies the list of
returned authentication methods and only offers a clear-text
password transaction. In order to avoid this type of
attack, only authentication methods with a challenge response
mechanism should be used.
Since all administration commands for RFC1459 and IRCX are
sent in clear text, a stream layer encryption mechanism like
SSL[5] or IPSEC is required to protect the integrity and
confidentiality of the transactions. The mechanisms for
[Page 39]
INTERNET-DRAFT IRCX June 1998
establishing these connection are outside the scope of this
document.
11. Acknowledgements
Specific acknowledgments must be extended to the following
people as the editors of the previous versions:
Kent Cedola, Lisa Dusseault, and Thomas Pfenning
In addition it has benefited from many rounds of review and
comments. As so, any list of contributors is bound to be
incomplete; please regard the following as only a selection
from the group of people who have contributed to make this
document what it is today.
In alphabetical order:
Josh Cohen, Alex Hoppman, David Kurlander, Robert Uttecht, and
Teoman Smith
12. References
[1] "Internet Relay Chat Protocol", Network Working Group RFC
1459, J. Oikarinen, D. Reed, May 1993
[2] The Unicode Consortium, "The Unicode Standard Version
2.0", Addison Wesley Developers Press, July 1996
[3] "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
Network Working Group RFC 2060, M. Crispin, December 1996
[4] "Simple Authentication and Security Layer (SASL)", Work
in Progress, draft-myers-auth-sasl-07.txt, J. Myers, December
1996
[5] "The SSL Protocol Version 3.0", Work in Progress, draft-
ietf-tls-ssl-version3-00.txt, Alan O. Freier, Philip Karlton,
Paul C. Kocher, November 1996
[6] "Tags for the Identification of Languages", Network
Working Group RFC 1766, H. Alvestrand, March 1995
13. Authors' Addresses
Dalen Abraham
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: dalena@microsoft.com
[Page 40]
